1. Technical Field
The present invention relates generally to network communication and in particular to network communication via transmission control protocol (TCP). Still more particularly, the present invention relates to a method and system for an improved retransmission mechanism during transmission of TCP packets.
2. Description of the Related Art
Transmission Control Protocol (TCP) is a protocol utilized to transmit data between nodes connected to the Internet. TCP operates as a transport layer protocol in an upper layer for Internet Protocol (IP) operating in a network layer, and is commonly referred to as “TCP/IP.” TCP implements a congestion control mechanism using acknowledgement (ACK) information transmitted to acknowledge reception of a data packet.
In TCP communication, data segments are transmitted as packets with unique sequence numbers (or packet IDs) from a transmission/origination terminal to a receiving/destination terminal. When the receiving terminal receives a data segment, the receiving terminal transmits an ACK having the same sequence number as a sequence number of the received data segment. The term “data segment” refers to a unit of a data block transmitted with TCP, referred to as a protocol data unit (PDU). In TCP communication, a transmission terminal simultaneously transmits as many data segments as possible within a period of time, referred to as a congestion window (CWND), even though the transmission terminal may not receive the ACK from a receiving terminal.
If the transmission terminal receives multiple ACKs with the same sequence number, (duplicate ACKs), the transmission terminal retransmits the data segment with the corresponding sequence number. Even through the transmission terminal does not receive the duplicate ACK, if the transmission terminal fails to receive an ACK for a predetermined timeout period after transmitting a data segment to the reception terminal, the transmission terminal retransmits the data segment.
A TCP receiver typically sends an immediate duplicate ACK when an out-of-order segment arrives. The purpose of this ACK is to inform the sender that a segment was received out-of-order and which sequence number is expected. A significant portion of duplicate ACKs are as a result of dropped packets/segments and/or the re-ordering of data segments during transmission through the network.
TCP utilizes a mechanism/algorithm called “Fast Retransmit” (described in IETF rfc2581 available at http://rfc.net/rfc2581.html) to quickly detect and repair loss of packets identified by receipt of incoming duplicate ACKs. Within this algorithm, the receipt of a duplicate ACK is considered an indication of packet loss. The fast retransmit algorithm uses the arrival of 3 duplicate ACKs (4 identical ACKs without the arrival of any other intervening packets) as an indication that a segment has been lost (or reordered). On receiving three such duplicate ACKs, TCP performs a retransmission of what appears to be the missing data segment, without waiting for the retransmission timer to expire.
The Fast Retransmit algorithm is not triggered, however, if enough duplicate ACKs (i.e., 3) are not received within the retransmission timeout period. Thus, there is a particular problem scenario in which the Fast Retransmit algorithm does not get duly triggered, even thought the packet has been lost. An example code of the faulty operation of the fast retransmit algorithm is illustrated by FIG. 1.
FIG. 1 illustrates a basic IP network 100 having a transmitting terminal 110 and a receiving terminal 120 connected to a network 115, such as the Internet. Also illustrated are a series of transmission of data segments across network 115 from transmitter 110 to receiver 120 and transmission of ACK responses from receiver 120 to transmitter 110. The timing of the transmissions is tracked by a vertical timeline 130 with time increasing (0 to T) along the downward path of the timeline. Arrows indicate the direction of each transmission from or to the transmitter and/or receiver, and each ACK transmission is labeled and described as a step in the overall process (e.g., step 140, 145, . . . 160).
As shown by the sequence of ACK responses following the initial transmission of a data segment, because the window information of the receiver 120 has changed (from 32000 to 32500) with the last duplicate ACK (step 155), the transmitter 110 of the data is not able to ascertain whether the duplicate ACK resulted from the receipt of an out-of-order-packet. The transmitter receives the ACK but does not consider the ACK as a duplicate ACK. In many conventional implementations, the timer (counter) is reset to zero (i.e, CNT=0, rather than CNT=2). With this reset, the duplicate ACK tracking process has to start all over again. Thus, for implementations that reset the count to zero, three additional duplicate ACKs are then required to initiate a fast retransmit of the lost packet. Even for implementations that retain the count (CNT=2, in the above example), at least one additional duplicate ACK needs to be received before the retransmission algorithm is triggered to retransmit the data segment. If the transmitter is not in a position to send the required number of new packets (e.g., (a) if there are no more writes from the application that is currently waiting for a response to its request or (b) if TCP is limited by the congestion window), no more duplicate ACKs will be generated and the fast retransmit will not occur.
Several solutions have been proposed to solve the above problems with the fast retransmit algorithm. Among these solutions is the “Limited Transmit” algorithm (described at http://rfc.net/rfc3042.html), which is, however, not specifically designed to solve the problems with the Fast Retransmit algorithm described above. However, event the limited transmit algorithm does not work if the window information changes again (e.g., 32000 to 32500) in the subsequent duplicate ACKs, as typically occurs (per FIG. 1). Notably, limited transmit algorithm and the other proposed solutions all focus on making changes on the transmitter side of the process. Several other transmitter-side solutions are discussed at: http://info.iet.unipi.it/luigi/sack.html. Each such solution suffers from the same limitation as one or both of fast retransmit and limited transmit algorithms.